Software Defined Networking (SDN) is an approach to computer networking that employs a split architecture network in which the forwarding (data) plane is decoupled from the control plane. The use of a split architecture network simplifies the network devices (e.g., switches) implementing the forwarding plane by shifting the intelligence of the network into one or more controllers that oversee the switches. SDN facilitates rapid and open innovation at the network layer by providing a programmable network infrastructure.
A Service Function Chain (SFC) defines an ordered set of abstract service functions. A service function is a function that is responsible for specific treatment of received packets. A service function can act at various layers of a protocol stack (e.g., at the network layer or other Open Systems Interconnection (OSI) layers). A non-exhaustive list of abstract service functions includes firewalls, Deep Packet Inspection (DPI), Lawful Intercept (LI), server load balancing, and Network Address Translation (NAT).
In traditional non-SDN networks, building SFCs requires various manual steps such as configuring routing/switching policies and Access Control Lists (ACLs). Building and configuring SFCs is greatly simplified with SDN capabilities. In an SDN environment, the switches typically act as Service Function Forwarders (SFF). An SFF is connected to one or more service functions (e.g., firewall, NAT) and is responsible for forwarding traffic to one or more of those service functions, as well as handling traffic coming back from those service functions.
In a typical SFC scenario, a service function classifier classifies an incoming packet based on the contents of the header fields of the packet. Based on the classification, the incoming packet is assigned to an SFC and forwarded to an SFF that is connected to the first service function of the SFC. The SFF then forwards the packet to the first service function of the SFC. After the first service function finishes processing the packet, the service function forwards the packet back to the SFF. The SFF may then forward the packet to an SFF that is connected to the second service function of the SFC so that the packet can be processed by the second service function. A similar process is repeated until the packet traverses all the required service functions of the SFC.
The use of a Network Service Header (NSH) is becoming a popular solution to realize SFCs. This solution introduces a new header, called NSH, that is added onto packets. At ingress, a classifier function classifies the packet and adds an NSH onto the packet based on the classification. The NSH includes information regarding a Service Function Path (SFP). An SFP specifies a particular path in the network that packets must traverse. Once the NSH is added onto the packet, subsequent forwarding of the packet is based on the contents of the NSH. The use of an NSH eliminates the need to reclassify the packet at every SFF. An NSH thus provides the flexibility to classify packets independently from the controller that manages the SFCs. The coordination required between the SDN domain and the SFC domain is the common understanding of the SFPs.
The transition to NSH-based implementations will likely be a gradual process. Both non-NSH-based forwarding and NSH-based forwarding will likely coexist in many commercial deployments. In order for the SFC architecture to support SFC-unaware SFs (e.g., service functions that do not support NSH), a logical SFC proxy function may be employed. The SFC proxy sits on the path between an SFF and an SFC-unaware service function. The SFC proxy accepts packets from the SFF on behalf of the SFC-unaware service function. In the forward direction, the SFC proxy removes the SFC encapsulation (e.g., NSH) from a packet and forwards the packet to the SFC-unaware service function via a transport tunnel (e.g., a local attachment circuit). In the reverse direction, the SFC proxy receives the packet back from the service function, reapplies the SFC encapsulation, and returns the packet to the SFF for further processing along an SFP. Each time a packet needs to be processed by an SFC-unaware service function, the packet is processed by the SFC proxy in both the forward (SFF to SFC-unaware service function) and reverse directions (SFC-unaware service function to SFF), which causes the packet to incur additional latency and consumes valuable bandwidth.